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METHOD FOR RECEIVING AND RECONCILING 
PHYSICAL INVENTORY DATA AGAINST AN ASSET 
MANAGEMENT SYSTEM FROM A REMOTE LOCATION 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] Not applicable. 

STATEMENT REGARDING FEDERALLY SPONSORED 
RESEARCH OR DEVELOPMENT 

[0002] Not applicable. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

[0003] The present invention relates generally to receiving and reconciling physical inventory data 
with the data stored in an asset management system. More particularly, the preferred embodiments 
are directed to receiving and reconciling physical inventory data related to computing resources 
against an asset management database of those computing resources. 

Background of the Invention 

[0004] In industries where assets of a corporation have long life spans and are not very portable, 
keeping an up-to-date asset management database is relatively simple. Periodically, a person or 
persons may take printouts or spreadsheets of the asset management database to the various 
affected corporate offices and verify the existence and location of these long-life span, non- 
portable assets. Once all the assets are found, or their dispositions determined, the person or 
persons may simply take the printout or spreadsheet of the asset management database back to a 
home office computer and update the information. 
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[0005] While these techniques may work well in some industries, tracking computer and 
computing assets in this way is wholly insufficient. Reconciling the physical inventory against the 
asset management database in the prior art, the manual method, may take three months or more to 
complete, including the time it takes to complete the physical inventory, as well as the time to 
manually reconcile each database entry against what was collected in the physical inventory. 
Three months worth of time for computing resources is very long, resulting in the movement, 
obsolesce, and replacement of a significant number of the computing resources before a manual 
method reconciliation can be completed. That is, because of the speed at which computing 
resources are outdated by advances in the computer industry and replaced, and also given the fact 
that the computing industry as a whole is moving towards smaller and more portable devices, these 
methods of reconciling the physical inventory of computing resources against those contained in an 
asset management database are insufficient. 

[0006] Thus, what is needed in the art is a way to reconcile the physical inventory of computing 
resources against the entries in an asset management database very quickly, so that the asset 
management database is truly representative of the quantity, location, ownership and types of 
computing resources within the company. 

BRIEF SUMMARY OF THE INVENTION 
[0007] The problems noted above are solved in large part by a method and related system for 
reconciling a physical inventory of computing assets against corresponding entries in an asset 
management database. Preferably, the physical inventory is taken using a hand held scanning 
device. Each computing resource within the company or within the particular site of the company 
is preferably marked with bar codes that indicate both the serial number of the device as well as an 
asset number. Thus, for example, a computer in a particular work area may be scanned using the 
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hand held device, and in just a matter of moments, the serial number and asset code for that device 
are stored in the scanner. The method also preferably involves marking each location or work area 
with a bar code such that the location of the computing resource may be entered into the scanner by 
scanning that related bar code. The location bar code may also include owner name information, 
or provide an index to supply the owner name information indirectly. Once the physical inventory 
is complete, or many times throughout the process if the company or site is large, the information 
in the scanner is up-loaded, preferably using an FTP program, to a directory on a web-based site. 
A conversion program preferably monitors that location on the web-based site, and upon the 
presence of files from the scanner containing asset information, scanner files, the program 
preferably converts that information into an intermediate SQL database. At roughly the same time, 
a copy of the main asset management database is made. 

[0008] Once each of the intermediate database and copy of the most current or main asset 
management database are available, a web-based interface is invoked which allows the user to 
compare entries from the intermediate database to those of the most current copy of the main asset 
management database. Preferably, similar records are pulled based on having similar asset codes; 
however, any of the database entries may be useable in pulling these similar records. Once the two 
similar records are compared, the user, again using the web-based interface, makes any necessary 
changes and accepts or rejects the overall record. Once accepted, a program periodically executed 
on the web server updates information in the main asset management database based on the 
information contained in each accepted record. 

[0009] Thus, a person or persons taking physical inventory can not only perform the physical 
aspects of that inventory, but because the steps of reconciling the data with old asset management 
information may be done using the web-based viewer, it is possible that updates to the main asset 
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management database can be done very quickly with respect to the physical inventory. Indeed, 
depending upon the size of the company or site and the number of people performing the physical 
inventory, it is possible to have the main asset management database up-to-date within a single day 
or less. 

[0010] A second aspect of the invention addresses identifying assets that were not found in the 
physical inventory. In particular, this aspect of the invention involves modifying the main asset 
management database to include some identifying indicia in each record, preferably appending a 
"WH" to the end of each seat or location code, such that the original entries in the main asset 
management database are identifiable. The location, which may also be referred to as a seat, 
uniquely identifies the location of an asset. As discussed above, the process of reconciling the 
physical inventory records with the main asset management database, while preferably taking a 
very short time, may also include work over several days in which each day some of the physical 
inventory data may be reconciled with old data and updates made to the main asset management 
database. Preferably, each accepted record written back to the main asset management database 
has a seat code that does not include the appended indicia. Thus, once reconciliation of the 
physical inventory to the main asset management database is complete, the user need only scan the 
main asset management database for assets at the seat codes still including the identifying indicia. 
Any entries at seats still having the identifying indicia were not identified in the physical inventory 
of the computing assets. This embodiment of the invention also envisions producing a record of 
new assets added to the main asset management database by use of the physical inventory/web 
acceptance method by producing audit trails of each update to the main asset management 
database. Thus, new assets added to the database may be identified through the audit trails. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



[0011] For a detailed description of the preferred embodiments of the invention, reference will 
now be made to the accompanying drawings in which: 

[0012] Figure 1 shows a flow diagram of a first portion of the steps of the preferred embodiment; 
[0013] Figure 2 shows a flow diagram of a second portion of the steps of the preferred 
embodiment; and 

[0014] Figure 3 is a block diagram showing the interaction of various files, programs, and systems 
of the preferred embodiments. 

NOTATION AND NOMENCLATURE 
[0015] Certain terms are used throughout the following description and claims to refer to particular 
system components. As one skilled in the art will appreciate, computer companies may refer to a 
components, software and methods by different names. This document does not intend to 



distinguish between components, software and method s that differ in name b ut not funct ion. 
[0016] In the following discussion and in the claims, the terms "including" and "comprising" are 
used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited 
to...". Also, the term "couple" or "couples" is intended to mean either an indirect or direct 
electrical connection. Thus, if a first device couples to a second device, that connection may be 
through a direct electrical connection, or through an indirect electrical connection via other devices 
and connections. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0017] In broad terms, the preferred embodiments of the present invention address reconciling 
physical inventory of computing resources /against a main asset management database with 
sufficient efficiency that the reconciliatiomprocess can produce an updated main asset management 
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database in a time span shorter than the assets and asset locations ire subject to change. Given that 
the preferred embodiment is directed to computing resource?; this time frame must be relatively 
small. While the preferred embodiments were developed/in the context of managing computing 
assets, and they will be described in that context, it/must be understood that the methods and 
systems described herein could be used for any asset management system and are not limited to 
tracking just computing assets. / 

[0018] Figure 1 shows a flow diagram of a/first portion of the preferred embodiments of the 
invention. The process starts at block 10. A first step of receiving and reconciling physical 
inventory data preferably starts by scanning a location code identifying a particular location, as 
indicated at block 12. In the context of taking a physical inventory of computing devices, this 
location preferably refers to a place, within the corporation or within a particular site of a 
corporation, where computing assets are placed. The location, which may also be referred to as a 
seat, uniquely identifies its .location. The location code is preferably such that it may be 
represented in a bar code fonnat which may be scanned by typical scanners. The step of recording 
the location of the computing asset is preferably accomplished by way of a hand held scanner 
capable of reading bar/codes and storing read information within scanner memory. The location 
may also provide an index to provide owner name information, or the owner name may be entered 
by way of the scanner. Although any of an array of scanners may be utilized in this capacity, the 
preferred method/and system involves the use of a scanner made by Point of Sale System Services, 
40 Jytek Drive/Leominster, Massachusetts 01453-5966. The particular model of the scanner used 
from this supplier was the Ultra, advertised as a programmable bar code scanner with display, key 
pad and bar code printer. 
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[0019] After scanning a location code, the next step in the physical inventory process preferably 
comprises scanning asset codes of computing assets at the particular location, as indicated at 
block 14. If, for example, the location under scrutiny is an office of an individual, there may be 
many computing assets within the office including, but not limited to, a computer, a docking 
station if the computer is portable, a display device, printers and scanners. Much like scanning the 
location codes above, preferably each computing asset has a bar code attached thereon with a 
unique asset code. Thus, scanning the asset code is as simple as using the hand held scanner to 
read the information. Also, the bar code may and preferably does identify the serial number of the 
device, which may further be used for tracking purposes. Regardless of the number of individual 
computing assets, preferably each of those are scanned as indicated at block 14. The scanner used 
preferably links together all the information regarding computing assets scanned at a particular 
location with the location code. 

[0020] The next step, still referring to Figure 1, is to continue the process at other locations within 
the corporation or particular site. Additional locations and related computing resources are 
scanned as indicated by the combination of blocks 16, 12 and 14. Once a sufficient number of 
locations within the corporation, or portion of the corporation, have been scanned, the next step in 
the process is to transfer the information stored in the hand held scanner, scanner fiies, to a 
predefined location on a web server, as indicated in block 18. 

[0021] Referring now to Figure 3, there is shown, in block diagram form, interaction of various 
files, programs and systems of the preferred embodiment. With regard to the transfer of the 
scanner files from the hand held scanner to the web server as indicated in block 18 of Figure 1, 
Figure 3 shows that the scanner file 40 is preferably transferred by means of an FTP program, as 
indicated by arrow 42, to a particular file location on a web server. Although the preferred method 
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is an FTP transfer, now understanding the function performed one of ordinary skill in the art could 
easily devise many equivalent ways to transfer the information from the hand held scanner to the 
web server. This could include, but is not limited to, having a hand held scanner capable of 
broadcasting that information using electromagnetic waves, or the information could be copied to a 
disk or other semi-permanent storage device and then manually moved between the hand held 
scanner and the directory in the web-based served. Further, there may be intermediate steps 
between the scanner file located on the hand held scanner and the web-based server, including 
transferring that information to other computers, such as a laptops or desktop device, which in turn 
transfer the information to the desired location on the web-based server. 

[0022] In the preferred embodiment, the information obtained by the scanner is preferably a 
comma delimited ASCII text file. While this is the preferred embodiment, one of ordinary skill in 
the art could easily devise many file structures which could equivalently contain the information. 
[0023] Referring now to Figure 2, there is shown a second portion of the exemplary physical 
inventory reconciliation. In particular, after transferring the comma delimited ASCII text file held 
in a hand held scanner to the web server, as indicated by the dashed line and arrow of Figure 1 
proceeding from block 18, the next step in the process is preferably to convert the scanner files into 
an intermediate database, as indicated in block 22. 

[0024] Referring again to Figure 3, block 44 exemplifies the raw scanner or raw inventory 
information from the hand held scanner placed in the particular location on the web server. As 
indicated by the arrow 46 of Figure 3, a conversion program preferably takes the scanner file on 
the web server and converts it to the intermediate database 48. In the preferred embodiments, the 
intermediate database is preferably an SQL format database. While this is the preferred database, 
any suitable database format may be used. Indeed, it would even be possible to implement the 
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invention where the database is simply some form of delimited ASCII text. Preferably, the 
intermediate database resides somewhere on the web server that held the scanner file. In the 
preferred embodiments of the present invention, the conversion program 46, when converting the 
ASCII text scanner file to an intermediate database, also creates additional database fields 
associated with each record. These additional fields comprise at least a date field and a user field. 
During the reconciliation process these fields are updated to indicate the date that each record was 
updated and the person performing that update. In this way, complete audit trails may be made 
respecting changes to the assets of the corporation. 

[0025] As is inherent in the flow diagrams of Figures 1 and 2, the process of the preferred 
embodiment does not necessarily proceed forward with only a single task operating at any one 
time. In particular, and as Figure 1 indicates, additional physical inventory tasks may take place 
while the steps of reconciling previously obtained information takes place, and as discussed more 
fully below with respect to Figure 2. In this regard, the conversion program 46, which is 
preferably a visual basic program written to perform the steps outlined herein, is programmed to 
periodically check the particular location in the web based server where the raw scanner files will 
be placed. The conversion program 46 may check for the presence of a scanner file hundreds or 
thousands of times before finding that scanner information has been placed in the particular 
directory. Upon finding a file containing that information, the conversion program performs the 
conversion from the preferred comma delimited ASCII text file as raw scanner data into an SQL 
database, to be the intermediate database 48. 

[0026] Referring again to Figure 2, preferably the next step in the process is copying the main 
asset database, as indicated in block 24. The main asset database 50 (Figure 3) is the database that 
contains all the asset management information regarding computing resources (or any other assets 
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that need to be tracked). In the preferred embodiment, this database is an SQL database, however, 
as discussed above with respect to the intermediate database, any database format may be 
equivalently used. Copying of the main asset database is done so that the records contained in the 
intermediate database 48 may be compared to and reconciled against this copy of the asset 
management database 52. 

[0027] Referring again to Figure 2, the next step preferably involves reconciling the physical 
inventory as embodied in the intermediate database 48, against/Uie corresponding records in the 
copy of the main asset management database, as indicated at mock 26 of Figure 2. With reference 
to Figure 3, reconciling the physical inventory against the copied asset database preferably takes 
place by way of a web user interface 54. That is tp say, a person or persons responsible for 
reconciling the physical data against the corresponding entries in the asset management database 
preferably performs this task by means of web>access. Web access is preferably provided by an 
Internet Explorer® web browser, however, /any available web browser may be used for this 
purpose. By way of the web browser, thevperson responsible for reconciling the physical inventory 
data against that of the main asset database invokes a reconcile program 56. The reconcile 
programs initially ask for a user ID suid password, which are then preferably used for creating audit 
trails as to changes in the main a^set database. Once past the log-in stage, the reconcile program 
invoked by the web browserTpreferably written in HTML or ASP programming language, pulls 
corresponding records from the intermediate database 48 and the copy of the main asset database 
52 and displays that information on the screen. While it may be possible to identify 
"corresponding assets^ by any of a number of identifying indicia, preferably the asset code is used 
for making this determination. Consider for purposes of example, and without limitation, that at a 
particular location within the physically inventoried location that a laptop computer has an asset 
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code 111. In the physical inventory, this asset code is associated with a location where that asset 
was found. Preferably the reconciled program 56 pulls corresponding entries from the 
intermediate database 48 and the copy of the asset database 52 based on this asset code. If the 
particular laptop computer with the/exemplary asset code 111 is in the same location as of the 
physical inventory as reflected in the asset database, then no change is required with respect to that 
asset, and thus the record is marked as accepted. 

[0028] Consider also the situation where the exemplary laptop computer with asset code 1 1 1 is 
found in a different location in the physical inventory than is reflected in the asset database. In this 
case, the person reconciling the records may accept that the new location is correct, may reject that 
record, or may make no change to the asset's location, regardless of the physical inventory. If, 
however, the person reconciling the physical inventory against the asset database believes that the 
physical inventory is correct, the location code associated with that asset may be updated and that 
particular record marked as accepted. 

[0029] Once reconciliation has completed with respect to all the assets found, the process of 
reconciling records may continue again, as indicated by block 28. Here again, decision block 28 of 
Figure 2, much like decision block 20 of Figure 1, is indicative of the fact that the preferred 
embodiments of the present invention are not limited to performing a single task at any one time. 
Thus, while one person is taking the physical inventory as indicated in the steps of Figure 1, a 
second person may be reconciling the data obtained from a previous portion or previous physical 
inventory, the steps represented in Figure 2. 

[0030] Once reconciliation of a particular set of data is complete, that data is preferably written to 
the main asset database as indicated in block 30. Referring again to Figure 3, an update 
program 58 periodically scans for accepted records in the intermediate database 48. When 
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accepted records are found, the update program 58 preferably copies or moves the accepted records 
from the intermediate database to the main asset database 50. The update program 58 of the 
preferred embodiments was written in visual basic, however, any programming language may be 
to create a program for this task. Moreover, in the preferred embodiment, the conversion program 
46 and the update program 58 are embodied in a single computer program. 

[0031] Referring anew to Figure 3, the process is described again briefly so as to tie together all 
the various components and programs. In particular, the scanner file 40 is preferably the comma 
delimited ASCII text files containing the physical inventory data gathered by the hand held 
scanner. The physical inventory data comprises at least a location code and asset code for each of 
the computing assets inventoried. At any time in the physical inventory process, the information 
held within the hand held scanner may be transferred to a particular directory on a web server, as 
indicated in block 44. Preferably this transfer is by FTP, but the mechanism of the transfer of the 
data in the scanner file may take many forms. A conversion program 46 checks for the presence of 
raw scanner data in the particular directory of the web server on a periodic basis. When the 
conversion program 46 finds a transferred scanner file, the conversion program 46 preferably 
converts the scanner file into an intermediate database 48. If multiple people are performing the 
physical inventory, after transfer of the scanner file 40 to the particular place on the web server 44, 
the person responsible for gathering the physical inventory data may continue that process while 
another person performs the reconciliation process. The person responsible for reconciling the 
scanner data against the old data preferably accomplishes this task by way of a web user interface 
54. Through this web user interface 54, a reconcile program 56 is invoked. Just prior to the 
reconciliation process, or possibly even triggered by it, a copy program 60 preferably copies the 
main asset database 50 to become the copy of the asset database 52. Through the use of the 
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reconcile program 56, corresponding records are displayed, preferably based on asset codes, 
between the intermediate database 48 and the copy of the asset database 52. Differences between 
the corresponding records in the intermediate database 48 and the copy of the asset database 52 are 
preferably highlighted for easy recognition by the user. The physical inventory data may thus be 
accepted or rejected, but if accepted, the particular record is marked as such. Preferably an update 
program 58 checks the intermediate database 48 for accepted records, and if any are found, that 
update program writes the new data to the main asset database 50. It is noted that, while not 
preferred, reconciliation may also take place directly against the main asset management database 
without departing from the spirit and scope of the invention. 

[0032] Now understanding the process steps and programs involved in reconciling the physical 
inventory data against the main asset database, it is seen that this system and related method has 
significant advantages over prior art "manual" methods of reconciling physical inventory against 
asset databases. It is also seen that while described in the context of computing resources, the 
system and method is easily applicable to a variety of assets, e.g., assets of a retail store or 
wholesale warehouse. 

[0033] A second aspect of the invention involves determining, from reconciliation to 
reconciliation, which computing resources or assets were not found in the physical inventory. In 
the preferred embodiment, making this determination involves invoking a seat code append 
program 62 (Figure 3). This seat code append program preferably modifies the main asset 
database 50 in such a way that any particular asset code that was not updated in the one or more 
reconciliation processes may be quickly and easily identified. 

[0034] More particularly, the seat code append program 62, preferably a visual basic program, 
appends to each seat code in the main asset database 50 some identifying indicia. In the preferred 
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embodiment, preferably a code "WH" is appended to the end of each seat code. As assets are 
identified in the reconciliation process, the found assets are written to the main asset database 50 
associated with new locations, locations without the identifying indicia. If all assets associated 
with a location having the "WH" are transferred to new locations, the location with the identifying 
indicia is completed removed. Once the overall physical inventory and reconciliation process is 
complete, the user need only scan the main asset database for any remaining at seats with the 
identifying indicia, the "WH" appended to their asset code. Simply put, these remaining at seats 
still having the identifying indicia were not found in the physical inventory, and may require 
additional work. 

[0035] The above discussion is meant to be illustrative of the principles and various embodiments 
of the present invention. Numerous variations and modifications will become apparent to those 
skilled in the art once the above disclosure is fully appreciated. It is intended that the following 
claims be interpreted to embrace all such variations and modifications. 
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